information security (情報安全保障)

他分野

安全保障は古代ローマにおいて精神的な心の平穩を意味する Securitas を語源とし、英語では Security やフランス語では Sécurité、ドイツ語では Sicherheit、イタリア語では Sicurezza、スペイン語では Seguridad と表記され、かうした歐洲の槪念を日本などが輸入した結果、漢字表記としての安全保障といふ槪念が成立することとなった。古代ローマにおける securitas といふ槪念はストア哲學の基本槪念のひとつであり、政治的社會的な意味を帶びた結果、ローマ帝國時代における「ローマによる平和」卽ちパクス・ロマーナ（Pax Romana）といふ槪念に結び附けられるやうになった。

1530s, "without care, dreading no evil," from Latin securus, of persons, "free from care, quiet, easy," also in a bad sense, "careless, reckless;" of things, "tranquil; free from danger, safe," from *se cura, from se "free from" (see secret (n.)) + cura "care" (see cure (n.)).

In English, of places, "free from danger, unexposed," from 1580s. Meaning "firmly fixed" (of material things) is from 1841, on notion of "affording grounds for confidence." Of telephones, "not wiretapped," from 1961. Replaced Middle English siker, from Old English sicor, from the Latin word. Related: Securely.

software とその life cycle の全體圖を書いて各部分の risk と對策を書きたい

BYOD (Bring Your Own Device) とかは直接には見なかった事にしてる

CSIRT とかは端っこだけ見たい。がっつりここでは扱わない

傳統的な三つ (CIA)

機密性 (confidentiality)

情報への access を認められた者だけが、その情報に access できる狀態を確保すること

許可されてゐない個人、entity 又は process に對して、情報を使用不可又は非公開にする特性

正しい権限

完全性 (integrity)

情報が破壞、改竄又は消去されてゐない狀態を確保すること

資產の正確さ及び完全さを保護する特性

正しい data

可用性 (availability)

情報へのアクセスを認められた者が、必要時に中斷することなく、情報及び關聯資產にアクセスできる狀態を確保すること

許可されたエンティティが要求したときに、アクセス及び使用が可能である特性

追加の四つ (上記三つから抽出されたとも謂へるが、獨立した地位を與へるに相應しいと見做された)

眞正性 (authenticity)

ある主體又は資源が、主張どおりであることを確實にする特性。眞正性は、利用者、プロセス、システム、情報などのエンティティに對して適用する。

責任追跡性 (accountability)

あるエンティティの動作が、その動作から動作主のエンティティまで一意に追跡できる事を確實にする特性。

監査 log

否認防止 (non-repudiation)

ある活動又は事象が起きたことを、後になって否認されないやうに證明する能力

信賴性 (reliability)

意圖した動作及び結果に一致する特性

正しい處理

HTTPS の檢査 tool

「金庫には「開く」と云ふ脆弱性が有る」って寓話

「正常に開く」と云ふ第一段階の脆弱性

出來るだけ開けない、開く條件を出來るだけ一堂に會させない

正常には開かなくする

差分 privacy 等、情報を削減する

有用な情報が殘ってゐる點や、複數の情報源を合せれば有用な情報を復元出來る可能性が有る事に注意する

「こじ開ければ開く」と云ふ第二段階の脆弱性

情報を發生させない、保存しない

要るからやるのだそれは當然だ、と思ふだらうが、「いつものやり方ではやる事に成ってゐる」事は見直せと云ふ事

unlearning (學び解し)

原理的に考へませう

「境界防禦」の考へ方は好くないと思ふ

「そのに境界が有り、防禦しよう」と言ふのはよいこと

ぢゃあ境界防禦はいいんぢゃん

さうだよ

「そこに境界は無い、防禦してはいけない」と言ふな

境界で防禦する、のではなく、防禦する所に境界を設けませう

それを「境界防禦」と呼んでも好い

見出せる境界だけを見て對策を講じてしまふ。何故そこに境界が有ると謂へ、何故そうではないところに境界が無いと謂へるのか考へづらい。考へると辻褄を合はせがち

security の問題が有り、その對策の爲にそこに境界を見出す、或いは作るのである

「境界防禦」でも語はよいのだけれども、境界の場所で防禦するのではなく、防禦する爲に境界を作る事を忘れないならその語でも好い。詰まり問題をやっつける役には立つが、問題を見附ける役には立たない事を忘れないならばその語でも好い

これを「zero trust」と最近は呼ぶのです

「傳統的にここが境界だと見做されてゐるところ」も本當はいちいち考へ直した方が好い。そのままその考へを使ふ事は多いけれども

security は保障でもあるが、攻撃者との對戰でもあるので「best practice」は無視せず信賴せず話半分に見ておく

原理的に考へませう

incident response

JPCERT/CC (一般社團法人 JPCERT コーディネーションセンター)

組織に於ける CSIRT の構成は病院に於ける集中治療室の構成と相同である

攻性のアレ

CVE/CVSS

risk

事象の發生確率と事象の結果との組合せ。

何かしらの損失を發生させる事態や狀況への可能性。また、考えられる脅威を分析した結果として認識される損失發生の可能性（リスク因子）を指すこともある。リスクの分析をリスク分析という。

脆弱性 (vulnerability)

一つ以上の脅威がつけこむことができる、資產または資產グループがもつ弱點。

リスクを發生させる原因。

脅威 (threat)

システムまたは組織に損害を與へる可能性があるインシデントの潛在的な原因。

脆弱性を利用 (exploit) して、リスクを現實化させる手段。自然災害も含まれる。

情報 security incident (information security incident)

望まない單獨もしくは一連の情報セキュリティ事象、または豫期しない單獨もしくは一連の情報セキュリティ事象であって、事業運營を危うくする確率および情報セキュリティを脅かす確率が高いもの。

發生する可能性の高い脅威。

情報 security 事象 (information security event)

システム、サービスまたはネットワークにおける特定の狀態の發生。特定の狀態とは、情報セキュリティ基本方針への違反もしくは管理策の不具合の可能性、またはセキュリティに關聯するかもしれない未知の狀況を示していることをいう。

risk 對應 (risk treatment)

リスクを變更させるための方策を、選擇および實施するプロセス。

脅威がリスクを現實化することを抑止（最小化）しようとする手段。對策ともいう。

security shift left

SecDevOps←DevSecOps←DevOpsSec

secure by design

secure coding

大垣靖男さんの

入力値 validation→正しい處理→出力値の確認 (出力先が validation しないならここで validation する) と sanitize

7PK (seven pernicious kingdoms)

1.1 Input validation and representation (入力 validation と表現)

1.2 API abuse (API の亂用 / 誤用)

1.3 Security features (security 機能)

1.4 Time and state (時閒と狀態)

1.5 Errors

1.6 Code quality (code 品質)

1.7 Encapsulation (cupsule 化)

1.8 Environment (環境)

CWE : Common Weakness Enumeration

M1 Establish and maintain control over all of your inputs.

M2 Establish and maintain control over all of your outputs.

M3 Lock down your environment.

M4 Assume that external components can be subverted, and your code can be read by anyone.

M5 Use industry-accepted security features instead of inventing your own.

GP1 (general) Use libraries and frameworks that make it easier to avoid introducing weaknesses.

GP2 (general) Integrate security into the entire software development lifecycle.

GP3 (general) Use a broad mix of methods to comprehensively find and prevent weaknesses.

GP4 (general) Allow locked-down clients to interact with your software.

CERT

第 1 入力を validation する

第 2 compiler の警吿に用心する

第 3 security policy の爲に構成／設計する

第 4 簡易にする

第 5 default で拒否する

第 6 最小權限の原則を支持する

第 7 他の system に送信する data を無害化する

第 8 縱深防禦を實践する

第 9 效果的な品質保證 technique を利用する

第 10 secure coding 標準を採用する

OWASP Top Ten

A01:2021-access 制禦の不備

A02:2021-暗號化の失敗

A03:2021-injection

A04:2021-安全が確認されない不安な設計

A05:2021-security の設定 miss

A06:2021-脆弱で古くなった component

A07:2021-識別と認證の失敗

A08:2021-software と data の整合性の不具合

A09:2021-security log と monitoring の失敗

A10:2021-server-side request forgery

A1:2017-Injection

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

A2:2017-Broken Authentication

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

A3:2017-Sensitive Data Exposure

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

A4:2017-XML External Entities (XXE)

Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

A5:2017-Broken Access Control

Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

A6:2017-Security Misconfiguration

Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

A7:2017-Cross-Site Scripting (XSS)

XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

A8:2017-Insecure Deserialization

Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

A9:2017-Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

A10:2017-Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

djb

HOW CAN WE MAKE PROGRESS?

Answer

Eliminating bugs

Enforcing explicit data flow

Simplifying integer semantics

Avoiding parsing

Generalizing from errors to inputs

Eliminating code

Identifying common functions

Automatically handling temporary errors

Reusing network tools

Reusing access controls

Reusing the filesystem

Eliminating trusted code

Accurately measuring the TCB (trusted computing base)

Isolating single-source transformations

Delaying multiple-source merges

Distraction

Chasing attackers

Minimizing privilege

Speed, speed, speed

提案してくれた 2 つの話題にはたぶん隔たりがある。一つは、原作者がセキュアにコードを書く方法としての、セキュアなコーディング。もう一つは、監査、つまり部外者（あるいは關係者のうち誰か）が後になってコードに殘ってゐるごみくちゃをきれいにしようとする過程。問題の一部はたぶん、この 2 つの閒に大きな違いがあるといふことだ。でも結局、そんな話題について扱った本では、徹頭徹尾、2 パラグラフ每に、同じことをくり返し書く必要があるだらう：

いまコーディングしているインターフェイスを理解しろ！

いまコーディングしているインターフェイスを理解しろ！　と。

俺達がソース・ツリーから監査であぶり出したほとんどのセキュリティ上の問題（あるいはただのバグも）はそこから來ている。問題となったコードを書いたプログラマは不注意なのろまで、自分が使っているインターフェイスに注意を拂はなかったのだ。ソース・ツリーのそこらぢゅうから繰り返し同じ種類のバグが出て來るといふ現實から俺達は、ほとんどのプログラマが（閒違った）用例でコーディングを學んだのだといふことを知った。堅固なシステムを作るには「動くんだからいいぢゃん」といふ土台で取り組んではいけない。にもかかはらず、何度も何度も、ほとんどの人々がさういふやりかたをするのを目にしてきた。連中は良いソフトウェアには關心がなく、「仕樣通り動く」ソフトウェアにしか興味がない。

だからプログラマ達はそんな失敗をし續けられるのだ。そんなわけで、俺は單に惡魔が潛んでいる場所を詳細に敎へるだけの本を書くことにはそんなに興味を持てない。今になってもその場所を知らないのなら、他の仕事（きっと引き起こすであろう損害が小さいやつ）を探すべきだ。

コードを監査する原動力は、必要性によるものでせうか、それとも BSD の設計から來たのでしょうか？　あるいはもとより思いつきなんでしょうか？　何より、どこでそれを學んだのでせうか？　共に見ている「先達」がゐらっしゃるのは、めりはりのある設計のためなのでせうか？　あなた方チームの壓倒されるようなコードのレビューには、感服せざるを得ません…自分にもあれほどの精細なコーディングの素質があれば良いのですが。

監査過程は、自分たちの OS の質を向上させようといふ欲求から生まれた。最初にそれを始めたときは、魅惑的で、樂しくて、そしてかなり狂信的に近いものがあった。約 10 人がその共同作業に携わって、原則としてお互いに敎へあひながら事を進めてきた。「ホール」や「バグ」といったものより、ソース・コードにおけるプログラマの基本的な誤りや杜撰な點を探した。ずぼらな點を見つけるたびにソース・ツリーを繰り返したどるといふことを、ずっとやってゐたのだ。プログラマが犯した誤りを見つけるたびに（たとえば mktemp(3) を使ってファイルシステム競合が起こるような場合）、ソース・ツリーを最初から最後までたどって、それら「すべて」を修正する。さうやって一つ直すと、他にも基本的な誤りを見つけるだらう。さうしたらまた「すべて」を修正する。そう、大變手閒のかかる作業だ。でもとてもただならぬ見返りがある。ボーイングの技術者が、發生した配線の不具合を「すべて」は直さなかったらだうなるかなんて想像できる？　少なくとも、ソフトウェアも同じやうにやるやうに試みませう。

コードを監査するに當たって、何かアドバイスをいただけませんか。今までバグを見つけてきた經驗から有用だった tips や方法に關して敎えていただけるとありがたいです。出來立ての若いコードの場合は、まずどこを探りますか？　古いコードの場合は？

一番の tips は、今よりももっと良いプログラマになる、ってことかな。特に、對象のプログラムがどんな函數を使ってゐるのか調べることと、そしてその函數の決まりごとをきっちりと守って使ってゐるか確かめることが重要だ。これを讀む人の中の果たして何人が、libc のすべての函數の完全で正しいセマンティクスを知ってゐるんだらう。全部と言はずに、今監査しているプログラムの中で使ってゐる libc の函數についてだけでも、ちゃんと分かってゐる人はどれだけゐるんだらうね。（だういふことかって言ふと、今までソース・ツリー全部を調べてきて、strncat() や strncpy() の呼び出しのだいたい半分は微妙に閒違ってゐて、一文字餘計にコピーしちゃってヌル終端しなくなるだけだとしても、それはやっぱりいい具合じゃないってこと。）

API を完全に身に附けた時に、簡單にバグを見つけることができるやうになるだらう。勤勉さが必要な他の仕事と一緒だと思ふよ。注意深くあって欲しい。人は前例から學ぶものなのに、依然としてソフトウェアプログラミングの世界では、その途方もない複雜さが見つけにくいバグを生み、それはさらに新しいコードにコピーされてゐるんだ。函數を閒違って定義したマニュアルを見つけたことすらあるんだけれど、その時には多くのプログラマが、閒違ったマニュアルに重ねて閒違ったプログラムを書いてゐた…。

NIST Special Publication 800-63

SP800-63A

SP800-63B

authenticator assurance level (AAL)

AAL1

AAL2

AAL3

SP800-63C

federation assurance level (FAL)

FAL1

Bearer assertion, signed by IdP.

FAL2

Bearer assertion, signed by IdP and encrypted to RP.

FAL3

Holder of key assertion, signed by IdP and encrypted to RP.

privacy

zero-trust

SELinux。AppArmor